[レポート] Top 10 DCL Tips & Tricks – JOIN@Home: JOIN Virtual Data Conference 2020 #JOINdata

本当に10個かどうかは数えてません

「カスタマーストーリー」を支えるツール特集

#ビジネス・アナリティクス

#ビジネス

#Looker

たまちゃん

2020.10.20

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大阪オフィスの玉井です。

米国時間の2020年10月13日から16日の計4日間に渡って、Looker主催のバーチャルデータカンファレンス『JOIN@HOME』が開催されました。

当エントリでは、「Top 10 DCL Tips & Tricks」というセッションについてレポートしたいと思います。

セッション概要

アジェンダページに記載されている当該セッションの概要は以下の通りです。

＜セッションタイトル＞
Top 10 DCL Tips & Tricks

＜セッション概要＞
Looker's Department of Customer Love brings you this list of the Top 10 Best Tips & Tricks we've discovered by working with all of the incredibly innovative customers of Looker. Get trained by the trainers on the best resources for learning Looker, troubleshooting problems, and building out your model and dashboards in a way that will optimize user adoption and delight.
(LookerのDCLが、お客様と一緒に仕事をすることで発見した、LookerのTipsやTricksのベスト10をお届けします。また、Lookerの学習、問題のトラブルシューティングなどで、モデルやダッシュボードを構築するための最良のリソースについても紹介します。)

セッションレポート

LookerのDCLとは

Lookerには「Department of Customer Love」という名前の部署がある
部署のミッション
- 顧客がLookerで素晴らしい仕事ができるよう支援する
- Lookerが顧客にとって素晴らしいものになるよう支援する（顧客からのフィードバックをLookerに反映する）
業務内容
- Lookerの機能やツールの使い方を教える
- 顧客のユースケースを聞いて、Lookerがあなたの仕事を最高のものにするために必要なことを確認する

今回のセッションの概要

Lookerのユーザー別に分けて、Lookerを使う上でのTipsやTrickを紹介する
- Explore
- Developer

Explorer向けのTips紹介

ダッシュボード

気になるLookを全部1つのダッシュボードにまとめようとしがち
- 理論的にはとても素晴らしいように思える
- しかし、これはハンマーだけで家全体を建てるようなものである
- そんな家はハリケーンであっけなく倒壊するだろう
1つのツールだけで全てをやろうとしない
ボードを使ってコンテンツをまとめる
- 特定の方法でキュレーションできる
- コンテンツを物理的に1箇所に集めるわけではないが、データのストーリーを伝えることはできる
1ダッシュボードに25個以上のタイルを配置しようとすると警告が表示される
- 26個以上置いても、全部のタイルが消滅するようなことはない
- Lookerのインスタンスが一気に処理できるクエリのボーダーラインが大体25個
- そして、1人の人間（の脳）が処理できるデータの量も大体これくらい
- （25個以上のタイルを配置したダッシュボードの全てを、一目で理解できる人間がいるか？という話）

オートリフレッシュ

ダッシュボードのデータを自動更新できる
更新の間隔を短くすると、常に新鮮なデータが表示できる
- しかし、データが1日間隔でしか更新されない場合、それ以上に頻度を上げる意味はない
更新頻度はETLに合わせること
- DBへのクエリも最小限にできる

データのエクスポート（ダウンロード）

Exploreのテーブルには、デフォルトで500件の結果が表示される
- 500以上のデータのダウンロードが必要な場合は、DBから直接ダウンロードする方が良い

スケジュール

ダッシュボードやLookのデータを定期送信する機能
大体の人は「月曜の午前9時」に配信を求める
- これをそのまま実行すると、ジョブが9時に集中してLookerのパフォーマンスに影響がでる
データがいつ更新されるか考えてスケジュールを設定する
- データが深夜に更新されるのであれば、スケジュール実行も深夜のうちに済ませればよい
- 午前9時に色々な人がLookerにアクセスするが、スケジュールジョブは無いので、パフォーマンスへの影響は少なくなる

Developer向けのTips紹介

modelの構築

「DBで早いクエリは、Lookerでも早い」ということを理解する
- なぜなら、LookerはSQLを投げているだけだから
- 逆にいうと、DBで遅いクエリはLookerでも遅い
SQL Runnerを利用する
- 実行計画を見ることが出来る
- 結合やインデックス等について確認し、modelを改良する
派生テーブルの永続化（PDT）について
- 「遅いけど必要なクエリ」があるかどうか見極める
- そういったクエリはPDTにすることでパフォーマンスが改善できる
- PDTの更新はETLのポリシーと合わせる
システムアクティビティダッシュボード
- （Lookerに接続している）DBのパフォーマンスを確認できる
- Looker上の遅いクエリを容易に特定できる

ProjectとDRY原則

includeは必要最低限にする
- viewやmodelをDBから自動生成すると、デフォルトで全viewがincludeされていたりする
- これはmodelの構築に全てviewをコンパイルする必要があることを意味する
- 命名規則やフォルダ等を利用して、必要なviewだけをincludeする
ProjectのImportを利用する
- 既に存在するProjectを簡単に持ってこれる
- 1からコードを書く必要が無くなる（時間節約）
- 既存リポジトリからコードをインポートすることも可
不要なExploreを掃除する
- 「コンテンツアクティビティ」を利用する
- 使われていないExploreがわかるので、それらを掃除する

テーブル計算とマージリザルト

テーブル計算
- Explore上でアドホックに計算ができる素晴らしいツール
- しかし処理は全てフロントエンドで行われる
- DBのパワーを使わないので遅い
マージリザルト
- すごく便利だが、永続的に使用するものではない（こちらもフロントエンド処理なので遅い）
- ユーザーがよく使うマージリザルト=必要な結合処理
- よく使われているマージリザルトを確認して、それらはDB側に落とし込むべき